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ABSTRACT 

The operation of interplanetary 
spacecraft at JPL has become an 
increasingly complex activity. This 
complexity is due to advanced 
spacecraft designs and ambitious 
mission objectives which lead to 
operations requirements that are more 
demanding than those of any previous 
mission. 

For this reason, several productivity 
enhancement measures are underway 
at JPL within mission operations, 
particularly in the spacecraft analysis 
area. These measures aimed at 
spacecraft analysis include: the 
development of a multimission, 
multisubsystem operations 
environment, the introduction of 
automated tools into this environment, 
and the development of an expert 
diagnostics system. 

This paper discusses an effort to 
integrate the above mentioned 
productivity enhancement measures. 

A prototype was developed that 
integrates an expert diagnostics system 
into a multimission, multisubsystem 
operations environment using the 
Galileo Power / Pyro Subsystem as a 
testbed. This prototype will be 
discussed in addition to background 
information associated with it. 

1. INTRODUCTION 

The operation of interplanetary 
spacecraft at JPL has become an 
increasingly complex activity. This 
complexity is due to advanced 
spacecraft designs and ambitious 


mission objectives which lead to 
operations requirements that are more 
demanding than those of any previous 
mission. JPL is now at a point where 
the current mission operations 
infrastructure is not sufficient to 
support future mission operations 
requirements unless this support is 
provided through increased staffing. 
Because of the cost constraints now 
being placed on spacecraft operations 
by NASA, staffing increases are not an 
option and an improvement over the 
current mission operations 
infrastructure is needed. 

In order to address this problem, 
several software development efforts 
are underway at JPL. One such effort is 
the Engineering Analysis Subsystem 
Environment (EASE) prototype. EASE is 
a collection of software programs 
providing a framework within which 
spacecraft engineering analysis can 
be done. This multimission , 
multisubsystem environment provides 
tools and a friendly graphical user 
interface to support spacecraft 
engineering analysis activities such as 
telemetry monitoring and 
performance predictions. 

Another effort that has been ongoing 
in order to address the mission 
operations problem is the Spacecraft 
Health Automated Reasoning Prototype 
(SHARP). SHARP is an expert system 
that contains subsystem specific 
knowledge which is used to provide 
diagnostics about that subsystem. 
SHARP was developed to assist the 
engineering analysts in diagnosing 
anomalous behavior on the spacecraft 
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and recommending actions to take in 
these situations. 

Because the operations environment 
provided by EASE and the diagnostics 
capabilities provided by SHARP 
compliment each other, the two 
prototypes were integrated to provide a 
more complete operations 
environment for spacecraft 
engineering analysis. This integrated 
system uses the Galileo Power / Pyro 
subsystem as its prototype subsystem. 

Following is a discussion of the EASE / 
SHARP prototype in terms of its 
integration and rules. Background 
information concerning the JPL 
mission operations process, EASE, and 
SHARP is also provided. 

2. MISSION OPERATIONS 

Spacecraft operations at JPL involves 
several steps. It includes developing 
sequences to send commands to the 
spacecraft, receiving telemetry from 


the spacecraft, and analyzing this 
telemetry to characterize the 
spacecraft state. Figure 1 shows a 
simplified mission operations process. 

The uplink process is shown across the 
top of the diagram. It begins with 
science and engineering requests 
being mapped with the Deep Space 
Network (DSN) coverage and other 
requirements to create a mission plan. 
The mission plan is a time ordered set 
of activities. This set of activities is 
then expanded into a time ordered set 
of commands through preliminary and 
final sequence generation. The 
validation of sequences and resolution 
of conflicts is an interactive process 
between the sequence and spacecraft 
analysis elements of mission 
operations. 

The downlink process begins when the 
spacecraft sends telemetry via the DSN 
to the JPL Space Flight Operations 
Center (SFOC). This data is 
decommutated, stored in a database, and 
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FIGURE 1. A typical Spacecraft Operations Process 
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delivered to the engineering analysts. 

The engineering analysis downlink 
portion includes performance 
monitoring, trend analysis, anomaly 
investigation, performance 
assessment, and fault protection 
analysis. Uplink support functions 
carried out by engineering analysis 
include command parameter 
generation, sequence validation, and 
predict generation. [Ref. 1 - 3]. 

The EASE / SHARP prototype addresses 
the engineering analysis portion of 
the operations process. It provides a 
software environment within which 
engineering analysis tasks can be 
carried out more efficiently through 
automation, software tools, and expert 
systems diagnosis. 

3. THE ENGINEERING ANALYSIS 
SUBSYSTEM ENVIRONMENT (EASE) 

The EASE system is a modular 
multimission, multisubsystem software 
environment. For a particular mission, 
various mission specific subsystem 
analysis modules (SAMs) are added to 
the environment to provide subsystem 
specific telemetry processing. Figure 
2a shows the environment when 


applied to a single mission and 
populated with SAMs. In a typical case, 
the SAMs are as follows: 

® Attitude and Articulation 
Control Subsystem (AACS) 

• Command and Data 
Handling Subsystem (CDS) 

• Electrical Power 
Subsystem (EPS) 

• Propulsion Subsystem 
(PROP) 

• Systems Subsystem (SYS) 

• Telecommunications 
Subsystem (TELECOM) 

• Temperature Subsystem 
(TEMP) 

When two or more single mission 
applications are interconnected 
through a multimission graphical user 
interface (MMGUI), it forms a 
multimission analysis system as shown 
in Figure 2b. As can be seen from the 
diagram , the modular EASE 
architecture facilitates the integration 
of new SAMs for a specific mission in 
addition to applications for different 
missions. 

The functionality of the EASE 
environment is provided through 
common interface formats, common 
display windows, development tools, 
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analysis tools, and a Database 
Management System (DBMS). By using 
the environment as a framework, SAMs 
can be integrated efficiently. Also the 
DBMS and tools provide opportunity for 
automated data analysis and 
manipulation. 

The EASE prototype currently includes 
several subsystem modules such as: 

GLL PPS and CDS, Voyager (VGR) EPS, 
and Mars Observer (MO) PPS. The most 
developed of these subsystems is the 
GLL PPS. 

4. THE SPACECRAFT HEALTH 
AUTOMATED REASONING PROTOTYPE 

(SHARP) 

SHARP is a diagnostics system that has 
been described in depth in a previous 
report [Ref. 5] . It is written in LISP 
and has been developed for the VGR 
and Magellan (MGN) TELECOM 
subsystems. The VGR and MGN 
versions of SHARP are stand alone 
implementations that contain a 
diagnostics kernel, VGR and MGN 
specific TELECOM knowledge, and 
diagnostics displays. 

SHARP for the GLL PPS subsystem 
implementation contains just the 
SHARP diagnostic kernel and GLL PPS 
specific subsystem knowledge. 

5. THE EASE / SHARP SYSTEM 

The primary motivation for 
integrating SHARP into the EASE 
framework is to enhance the EASE 
operations environment developed for 
monitoring and analyzing the 
spacecraft data by adding capabilities 
for diagnosing the state of the 
spacecraft. Below is a discussion of the 
integration process of SHARP into EASE 
and the rules currently included in the 
SHARP diagnostics module. 

5.1 Integration 

The first step in the integration 
process was to separate the SHARP 


kernel from the rest of the SHARP 
system. An interface between the C 
and LISP programming languages is 
used to pass data from EASE to SHARP. 
SHARP uses this data to determine 
alarms and anomalies on the spacecraft 
and reports these back to EASE. A LISP 
to C programming language interface 
is used to send alarm and diagnostics 
messages form SHARP to EASE. 

These alarm and diagnostics messages 
contain a substantial amount of 
subsystem specific information. For 
channels in alarm, the messages 
contain the mission name, channel 
type, channel number, time, alarm 
limits, alarm state (high hard, low soft 
etc.), a title message, summary 
message, and a message key which 
points to a detailed message about the 
problem. The diagnostics messages 
contain similar information with most 
of the subsystem specific knowledge 
being included textually in the title, 
summary, and detailed messages. 

5.2 Rules 

The set of rules the prototype uses for 
testing is for diagnosis of a GLL PPS bus 
undervoltage. Although this is a rare 
anomaly, the reasoning process in 
determining the cause of a bus 
undervoltage is well understood 
providing a useful basis for developing 
and testing this prototype. The GIT. 

PPS power bus is tightly regulated 
between 30.1 and 31.5 volts. If the 
voltage on the bus goes under the 
allowable limit of 30.1 volts, the bus 
undervoltage rules within SHARP will 
trigger. SHARP uses all related 
telemetry in order to determine the 
cause of the anomaly. Possible causes 
for a bus undervoltage anomaly 
include a failure in a shunt regulator 
stage, a dc bus short, an ac bus short, or 
an ac inverter failure. 

Another set of rules in development 
for SHARP is for determining load 
status (power consumption value of 
loads). The GLL spacecraft has 121 total 
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FIGURE 3. The EASE /SHARP Display Screen 


dc and ac loads. Power status telemetry 
that gives visibility into these load 
states consists of the bus and ac 
inverter output voltages, and the ac 
inverter output, shunt regulator, and 
dc bus currents. Additional 
information such as thermal and 
command data must be used by SHARP 
in order to infer the state of each of 
the 121 spacecraft loads. Because of 
telemetry and processing constraints 
on the spacecraft, determining the 
state of spacecraft loads on GLL must be 
done by the Ground System. 

5.3 Displays 

The displays for the EASE / SHARP 
prototype are developed within the 
EASE environment. The "LISP" to "C" 
interface is used to pass data from 
SHARP to the EASE display module. 

In designing the displays, concerns 
about the overload of information 
whenever an anomaly or several 
alarms occur was addressed. The 
display design chosen for the EASE / 
SHARP prototype uses the concept of 
"layering" information to deal with 
this problem. "Layering", as used here, 
means presenting summary 
information to the user at all times. 
More detailed information concerning 
an alarm or diagnosis can be accessed 
by the user simply by clicking the 


mouse on the summary information. 

In this way, the analyst is aware of all 
alarms and diagnoses and can access 
any information about them, but is not 
overwhelmed with large amounts of 
detailed data. 

Figure 3 shows the GLL PPS block 
diagram shortly after the occurrence 
of a simulated bus undervoltage 
anomaly. The top three layers of 
display windows are shown on the 
right side. Layer 1 is the alarm panel, 
layer 2 the alarm summary, and layer 3 
the detailed alarm message. The 
operator may acknowledge or ignore 
alarms that are listed on the alarm 
summary table. 

6. CONCLUSION 

Through the development of 
prototypes such as the EASE / SHARP 
prototype, much can be learned about 
using software to improve the mission 
operations process at JPL This 
particular prototype has given 
valuable insight into the advantages 
of using a modular, multimission, 
multisubsystem architecture as a 
framework for integrating analysis 
modules such as SHARP. Data was also 
obtained concerning how to display 
large amounts of information, and the 
importance of operations 
considerations in spacecraft design. 
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into one system. Interface code from 
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modified and used to integrate SHARP 
and the new displays. The idea of using 
a common environment to provide 
displays, interfaces between modules, 
and common tools made the integration 
of SHARP into EASE straightforward. 

Because of the additional analysis 
information that was added to the EASE 
system through the integration of 
SHARP, the display of information 
became a concern. A "layering" 
approach was selected and was useful 
in showing the operator summary 
information, and allowing for detailed 
information to be accessed. 

A final point that was learned in this 
process is the possible implications of 
"operationally blind" spacecraft 
design. Much time was spent in 
knowledge engineering and software 
development for the load status rules. 
This would not be necessary if 
appropriate telemetry was provided 
from the spacecraft. The Cassini 
project has realized this and has 
included load current telemetry for all 
Cassini loads. This problem is not 
specific to the power subsystem, 
however, and early operations 
involvement in spacecraft design is a 
necessity at both the subsystem and 
system level in order to aviod problems 
such as this. 

The EASE / SHARP prototype has 
provided useful information in 
exploring the use of advanced software 
for mission operations. The purpose of 
these software packages is to provide 
functionality and assistance to the 
analyst so that fewer analysts will be 
needed for mission operations and cost 
reductions in this area will be possible. 
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